线上云展会面对突发事故，如何做好崩溃分析与性能监控？

2020-12-29

线上云展会面对突发事故，如何做好崩溃分析与性能监控？

会展云解决方案覆盖了业务，技术，平台，应用\四个层面，业务层面提供科技感十足的云上展厅、多种模式的论坛会议等；应用层面有多种解决方案，直播解决方案、视频会议解决方案、移动研发解决方案等；技术层面依托海量弹性云计算能力和充足可扩展的云存储及带宽资源，集成了多种京东中台平台的能力，有技术中台、数据中台、智能中台及业务中台能力，可快速响应前台应用的需求。

作为云上展会，最终呈现给广大参会者的对外窗口必然是网站、APP、H5、小程序*等线上系统。在京东会展云中，一站式APP解决方案EMOP平台也是其中重要一环，可为会展云举办方提供多种移动终端，包括APP、H5、小程序等，提供全业务流程的规划、设计、研发、运营、运维等一条龙服务。

不久前成功举办的中国国际服务贸易交易会（简称服贸会）首次采取新模式——线上线下展会融合，就借助EMOP平台在运维层面的能力，为服贸会APP的稳定运行保驾护航。

服贸会参与展会的企业多达17000余家，而服贸会APP作为云上展会对外运维的重要窗口，为来自全球不同规模、不同行业的参展商、采购商提供展览展示、论坛会议、洽谈签约的数字平台。

在展会举办期间，服贸会APP如何扛住客流量的压力？如何保障线上APP的质量？如何高效地修复线上崩溃问题？如何提升客户留存和活跃？

在寻找问题答案前，不妨先来看一个京东的案例，2020年京东6.18成交量超2692亿，创历史新高。618大促期间，京东APP有成千上万的用户去浏览商品、抢购、下单等，不仅要扛住亿级流量的压力，还要提供良好的用户体验，毫无疑问，这离不开其背后支撑的技术。

在遭遇到大型会展较大客流量冲击，面对突发事故，研发人员是怎样快速定位问题和及时修复，那必须得谈谈背后的崩溃分析系统和移动性能监控系统。

崩溃系统定位于为移动APP提供崩溃监控及崩溃模块定位的服务平台，通过对APP崩溃数据的监控和分析，从而协助APP降低崩溃频率，提升用户满意度，具有支持Android、iOS极简接入、实时监控、信息全面、安全稳定、统计详细等特点。

崩溃分析系统为APP的稳定运行起着保驾护航的作用，目前已经通过京东万商、京东到家、七鲜等众多APP的验证，此次服贸会APP接入崩溃系统，一是随时监测APP，保障展览展示、论坛会议、洽谈签约等功能的稳定运行；二是在短时间内定位崩溃模块所在，及时修复问题。

崩溃捕获：支持原生崩溃、OOM崩溃、自定义错误或异常上报；
崩溃分析：基于崩溃模块维度的聚类分析，通过聚类数据分析快速发现问题主要特征；
跨端异常：支持跨端异常模块查询，跨端异常数据解析（RN、Flutter），快速定位跨端问题；
高级功能：针对各种异常信息进行详尽的搜索查询，支持原始数据导出，支持不同查询条件的对比查询。

移动性能监控系统旨在建立统一的应用性能接入框架，通过各种性能监控方案，对客户端数据进行采集，展示异常数据，辅助定位异常问题并输出性能报告，从而协助开发者快速发现产品性能问题，优化APP性能。

性能分析像是为APP把脉的老中医，各种疑难杂症都可快速揪出来。

在大会举办期间服贸会APP上线运行后，通过性能分析实时感知应用启动性能、页面加载性能、网络请求等状态，定位异常问题所在，保障参展商，采购商，媒体记者等良好的使用体验。

通过以下几个功能：启动监控、卡顿监控、网络监控、webview监控，原生页面监控以及日志上报、安装包分析工具、内存分析工具可实现性能监控。

（一）启动监控

监控线上用户启动应用的耗时以及定位到时间消耗在了哪些阶段。

启动监控采用了无侵入式打点方式分为了三个阶段，记录了应用启动各个阶段的耗时情况：

第一阶段： 记录了Application的初始化阶段耗时；

第二阶段： 记录了Application初始化完成后到用户首页开始创建的耗时

第三阶段： 记录了首页开始创建到完全展示过程的耗时

启动耗时 = 第一阶段耗时 + 第二阶段耗时 + 第三阶段耗时。

另外，对启动时期应用的主要生命周期的方法也做了方法执行时间上报，辅助用户通过直观的数据进行启动过程的拆解。

（二）卡顿监控

卡顿引发的原因有很多种，其中，主线程的卡顿带来的影响最为严重，可能会导致用户无法正常使用移动APP上的任何业务。

卡顿监控原理介绍：

① APP UI线程消息机制

APP UI线程是Looper线程，线程中维护一个消息队列，Looper在循环消费消息队列中的任务，如果消息队列中存在耗时的操作，将会影响UI任务的绘制，导致界面出现卡顿。

② 采集UI线程消息的运行时长

移动端（Android/iOS）都是采用了AOP的思想，对整个UI线程的消息处理过程进行了监控，采集到了每个消息的执行时间。

③ 卡顿条件（消息执行时间 > 卡顿阈值）

在采集到每个消息的执行时间后，自动进行卡顿阈值比较，超过阈值的消息被认为该消息执行时间过长，会引发主线程卡顿。

④ 采样

在执行主线程的同时，采样线程对主线程的堆栈、cpu等信息进行周期采样。但是采样线程要先休眠一段时间，这样做的最主要原因就是为了不对主线程大部分的短消息进行打扰，抢夺cpu资源，造成性能降低。

（三）网络监控

网络监控的数据包含了两大类：原生网络监控和图片监控

原生网络监控主要监控了接口的性能及异常数据；图片监控是在网络监控的基础上新增了CDN节点数据上报。

网络监控技术方案介绍：

① 采用ASM字节码编辑技术Hook到了App底层的基础网络组件的网络行为；

② 网络性能维度的采集将网络请求划分为几个阶段进行统计上报，帮助开发及运维同事快速定位网络的某个阶段问题，具有更好的准确性；

③ 整个网络监控包含了性能数据及异常数据这两类，既满足基本的异常告警监控，也具备分析聚合线上性能数据的功能；

（四）原生页面性能监控

原生页面监控采用较为轻量级的数据采集策略，主要通过运行期间，采集设备的帧率，CPU, 内存，线程数，流量这几种数据，来反应当前页面运行时性能情况。

技术方案介绍：

① 帧率采集

帧率采集方案是通过系统的回调监听页面的刷新事件，监听到页面开始刷新时便计算页面每帧绘制耗时，通过帧数/总耗时来计算出真实的帧率。

② CPU、内存、线程数据采集

CPU，内存使用情况及线程数量能够反映出原生页面的资源消耗情况，性能监控系统采用了等时间间隔采样的方式来实现样本采集。

CPU监控能够反馈当前页面的CPU使用情况，可以侧面反馈出电量消耗问题；
内存使用能够标明当前页面消耗内存情况及JVM中可用内存大小，从而计算出内存触顶率及页面内存抖动情况；
线程数可以监控到原生页面中是否线程数超标，监控线程数超标OOM问题。

（五）webview监控技术方案介绍

京东性能监控系统支持Webview与腾讯X5内核性能监控，监控的核心指标为window.perfromance.timing参数，该参数记录了整个webview加载过程中的阶段性耗时，详见下图：

通过浏览器内核返回的数据，可以计算出页面加载总时间、网络请求耗时、DOM加载时间、白屏时间即用户等待时间等性能指标。

以上两个系统在监控层面赋能服贸会APP的原理和实现，都来源于京东EMOP平台，该平台是企业级移动研发平台，结合“京东系”APP研发的经验积累与最佳实践，为移动开发提供一站式解决方案，可以帮助企业构建强大的移动中台，快速创建高质量的APP、各类小程序等移动终端产品，支持企业新业务开展，助力企业移动化转型顺利实施。

EMOP支持私有云和公有云部署，有四大稳定的开发框架，7种移动开发技术与组件能力，源于“手机京东”APP研发的最佳实践，在实现多业务闭环的前提下，解决成本、质量、效率、标准问题，助力多团队APP研发的质量提升、成本节约。